昨天談到，軟體邏輯和模型需要不同的測試方法。開發時，我們會針對需求設計一些測試，並且讓這些測試通過，接下來確認：這些測試涵蓋了哪些需求？前面風險分析提出的控制措施，有沒有對應的檢查？如果某項需求根本沒有測試，即使目前的測試全部通過，也看不出這個缺口。
所以，我們需要有一個方法來確保最初的法規與臨床需求，到程式碼的開發以及測試結果，因為每一個環節都是環環相扣，並且可以回溯查詢的。
所謂的回溯查詢，一邊是由需求往下追，確認每一項使用者需求、每一個風險控制措施，最後都有對應的設計、程式碼和測試把關；另一邊則是從程式碼和測試往上找，確認系統裡沒有憑空出現的功能，也沒有「寫了但不知道為什麼要寫」的程式碼。
所以在醫療軟體當中，「雙向追溯性（Bidirectional Traceability）」是非常重要的能力，透過雙向追溯性，能向前與向後追蹤所有研發產出，確保最終的產出與一開始的需求一致。
Intended Use（預期用途） → User Needs（使用者需求） → System/Software Requirements（系統/軟體需求） → Software Architecture & Design（軟體架構與設計） → Source Code / Software Units（原始碼/軟體單元） → Verification / Test Cases（驗證/測試案例）。Test Results（測試結果） → Test Cases（測試案例） → Software Design（軟體設計） → Software Requirements（軟體需求） → Risk Analysis / Hazards（風險分析/危害）。另外值得一提的是，IEC 62304 會依照軟體可能造成的傷害嚴重程度，把軟體分成三個安全等級（Software Safety Class）：
這個分級會直接影響追溯的嚴格程度。Class C 的軟體，從風險控制到測試結果的每一層連結都必須非常完整，審計時也會查得比較細；Class A 則相對寬鬆。
以我們這個「居家生命徵象追蹤 App」為例，因為涉及血壓異常可能延誤處置的風險，通常會落在 Class B，部分涉及 AI 摘要或關鍵警示的功能甚至可能被拉到 Class C。分級不同，RTM 該做到多細，其實也會不一樣。
在醫療軟體開發中，會將雙向追溯量化成一張需求追溯矩陣（Requirement Traceability Matrix，RTM）。這是一份動態的表格或資料庫連結，橫向或縱向地將以下的元素綁定：
$$\text{Hazard ID} \iff \text{Risk Control ID} \iff \text{Software Requirement ID} \iff \text{Design Specification ID} \iff \text{Test Case ID} \iff \text{Test Pass/Fail Result}$$
| 元素 | 中文名稱 | 要連到的內容 |
|---|---|---|
| Hazard ID | 危害編號 | 風險分析中的危害紀錄，包含相關情境與可能傷害的說明 |
| Risk Control ID | 風險控制措施編號 | 針對相關風險採取的控制措施，以及它要處理的出錯環節 |
| Software Requirement ID | 軟體需求編號 | 軟體必須做到的具體行為與接受條件 |
| Design Specification ID | 設計規格編號 | 實現需求的設計，例如表單狀態、資料歸屬與寫入流程；可再連到實作位置 |
| Test Case ID | 測試案例編號 | 測試條件、輸入、操作步驟、預期結果與判準 |
| Test Pass/Fail Result | 測試通過／失敗結果 | 某次測試執行的實際結果，並連到執行紀錄與報告 |
前面的範例中，「居家生命徵象追蹤 App」為例，將前幾天產出的需求（Day 8）、風險控制（Day 10）、介面防呆（Day 11-12）與資料模型（Day 14）整理成一張真實的追溯矩陣。
這裡特別標示出 「目前狀態與缺口」 —— 將「還沒做」或「只有單元測試、缺人因評估」，才是 RTM 在開發期發揮價值的關鍵：
| 追溯 ID | 預期用途 / 使用者需求 | 對應風險控制 (ISO 14971) | 軟體需求規格 (SRS) | 程式碼 / 模組 | 查證證據 (Verification) | 確效證據 (Validation) | 目前狀態與缺口盤點 (Gap Analysis) |
|---|---|---|---|---|---|---|---|
| TR-01 | 查看有語意脈絡的紀錄(UN-001) 能清晰辨識每筆量測的完整背景。 | R-01 單位誤配華氏當成攝氏顯示，可能延誤處置。 | SRS-001：呈現紀錄須含 systolic、diastolic、unit 與 measured_at。單位缺失或不支援時，標示「無法判讀」。 |
VitalRecordView.ktUnitConverter.kt |
TC-001 (Pass)JUnit 測試無單位時自動標示不可判讀。 | 【缺口】待安排模擬環境人因測試。 | 查證完成，確效尚缺(需要確認使用者是否看得懂「無法判讀」的提示)。 |
| TR-02 | 異常數值防呆(UN-002) 防止輸入顛倒數值影響紀錄。 | R-02 數據逆向收縮壓與舒張壓填反導致判定錯誤。 | SRS-008：當收縮壓 $\le$ 舒張壓時，阻擋儲存並跳出警告彈窗。 | VitalValidator.kt |
TC-008 (Pass)自動化測試確認收縮壓 80、舒張壓 120 時阻擋寫入。 | TC-V002 (Pass)10 位高齡試用者於模擬 UI 均能看懂警告並更正。 | V&V 完整(查證與確效證據齊備)。 |
| TR-03 | 離線與斷網寫入(UN-003) 斷網時能明白資料是否有存入。 | R-04 同步延遲以為舊資料已更新，忽略重新量測。 | SRS-012：斷網時存入本機，UI 標為 un-synced，連線後自動重試且不產生重複筆數。 |
SyncManager.ktLocalRoomDB.kt |
TC-012 (Pass)斷網與重試情境測試 Pass。 | 【缺口】待進行實際弱網環境測試。 | 查證完成，確效尚缺(需評估真實離線時是否會讓使用者產生重複點擊焦慮)。 |
| TR-04 | 避免紀錄錯置他人(UN-004) 切換家人時不混淆數據。 | R-03 病人誤配切換對象後沿用上一人的待送出數值。 | SRS-015：切換對象時自動清空未送出表單；寫入時核對 Patient ID 與授權。 | PatientSession.kt |
TC-015 (Pass)雙帳號交錯寫入測試 Pass。 | TC-V004 (Pass)照護者模擬多位家人輸入，無看錯或混淆對象。 | V&V 完整(查證與確效證據齊備)。 |
| TR-05 | AI 摘要邊界限制(UN-005) 數據不足時不給予誇大結論。 | R-05 超出範圍數據過少時 AI 給予錯誤趨勢推論。 | SRS-020：7 天內紀錄不足 4 筆時，AI 摘要僅列出數據，顯式標註「資料不足，無法分析趨勢」。 |
把公式中的 6 個核心節點與實戰表格的欄位進行一對一對照：
| 公式節點 | Day 26 表格對應欄位 | 實戰範例 (以逆向數據防呆為例) |
|---|---|---|
| Hazard ID & Risk Control ID | 對應風險控制 (ISO 14971) | R-02 數據逆向（收縮壓/舒張壓填反） |
| Software Requirement ID | 軟體需求規格 (SRS) | SRS-008（當收縮壓 $\le$ 舒張壓時，阻擋儲存並跳出警告） |
| Design Specification ID | 程式碼 / 模組 | VitalValidator.kt（驗證邏輯模組） |
| Test Case ID | 查證與確效證據 | • 查證 (Verification)：TC-008 (單元/系統測試)• 確效 (Validation)：TC-V002 (高齡試用者模擬操作) |
| Test Pass/Fail Result | 目前狀態與缺口盤點 | V&V 完整（單元測試 Pass 且人因測試 Pass） |
RTM 填完之後只是第一步，接下來是要利用它來找缺口，找尋還沒有完成的地方。實務上通常會從兩個方向一起看：
先從需求或風險控制往後查：這項需求有沒有寫清楚？有沒有對應的測試方法？風險控制有沒有真正落到設計和測試裡？
再從已經存在的功能或測試往回查：這個功能是從哪裡來的？為什麼要做？如果找不到來源，就不要急著補一條需求去合理化它。
另外有個很容易漏掉的情況是：連結看起來都有了，但測試案例只測了正常路徑，沒有覆蓋需求裡寫的失敗條件。這種時候表格上雖然連著，實際上證據還是不夠。
在醫療軟體開發當中，我們需要將需求以及風險對應到開發的項目上面。這個任務看似複雜，其實我們可以透過 RTM，將 RTM 填完之後，就可以輕鬆地查到哪個地方還沒有完成。
在實務上，使用 RTM 時，採用雙向追溯的方法（正向追溯、反向追溯），從不同的角度來看是不是有沒完成的需求，或者有完成的功能卻對應不到需求。如果有對不齊的地方，那就是需要去釐清、待釐清的部分。
如此一來，我們的開發項目就會滿足需求，避免有意外出現（意外開發出的功能、意外沒有滿足的需求）。
iThome鐵人賽
看影片追技術